Fault tolerance approaches for DNS server failures

ABSTRACT

Techniques are provided for handling failures of DNS (domain name system) servers to respond to DNS queries. A DNS resolver is configured to resolve domain names, and includes a time-to-live (TTL)-based cache, a negative cache, and a long term store cache. The TTL-based cache is configured to temporarily store domain names with resolved IP addresses. The negative cache is configured to store negative entries that include information indicating domain names that were failed to be resolved. The long term store cache is configured to store domain names with resolved IP address for an indefinite time period. The caches are accessed in a manner that enables fewer DNS query retries to be performed when a DNS server is non-responsive, to reduce delays and network traffic. Furthermore, the DNS resolver may reduce a number of DNS queries performed the longer the DNS server stays non-responsive.

This application claims the benefit of U.S. Provisional Application No.61/219,901, filed on Jun. 24, 2009, which is incorporated by referenceherein in its entirety.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to network communications that utilize theresolution of domain names to network addresses.

2. Background Art

Networks, such as the Internet, support various forms of communication.For instance, voice over Internet protocol (VoIP) is a general term fora family of transmission technologies for delivery of voicecommunications over IP networks such as the Internet or otherpacket-switched networks. For example, using VoIP, users are enabled tomake telephone calls over the Internet using communication devices suchas IP phones. When using a VoIP application, a user may expect to hear adial tone as soon as the user picks up the phone, and may expect to beable to make a call without any problems at any time. However, delays inreceiving a dial tone, and other issues, do occur with regard to VoIPtelephone calls. Such delays may have various causes.

For instance, the domain name system (DNS) is a hierarchical namingsystem for computers, services, and further resources participating incommunications on the Internet. Each communication device that isconfigured to communicate over the Internet may be identified by acorresponding DNS domain name, which has an associated IP address. Afirst communication device may desire to perform a VoIP (or other)communication with a second communication device. The firstcommunication device may identify the second communication device by itsdomain name. The first communication device may transmit a DNS querythat includes the domain name to a DNS server to obtain the IP addressfor the second communication device, to enable communications with thesecond communication device. However, a failure of the DNS query maycause a significant amount of network bandwidth to be consumed, becausethe first communication device may repeatedly transmit the DNS query infurther attempts to obtain the IP address for the second communicationdevice. If a large number of communication devices are simultaneouslyattempting DNS queries that are failing, large amounts of networkbandwidth may be consumed, and a voice service outage may even occur.

As such, techniques for avoiding network issues with regard to failedDNS queries are desired.

BRIEF SUMMARY OF THE INVENTION

Methods, systems, and apparatuses are described for handling failed DNSqueries and non-responsive DNS servers substantially as shown in and/ordescribed herein in connection with at least one of the figures, as setforth more completely in the claims.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings, which are incorporated herein and form a partof the specification, illustrate the present invention and, togetherwith the description, further serve to explain the principles of theinvention and to enable a person skilled in the pertinent art to makeand use the invention.

FIG. 1 shows a block diagram of a communication system, according to anexample embodiment.

FIG. 2 shows a block diagram of a communication system that is anexample of the communication system of FIG. 1, according to an exampleembodiment.

FIG. 3 shows a block diagram of a DNS resolver, according to an exampleembodiment.

FIG. 4 shows a block diagram of a communication device having a DNSresolver implemented therein, according to an example embodiment.

FIGS. 5A-5D each show portions of a flowchart for a DNS resolutionprocedure, according to an example embodiment.

FIG. 6 shows a block diagram of a DNS resolver, according to an exampleembodiment.

FIG. 7 shows example contents of a time-to-live (TTL)-based cache, anegative cache, and a long term store cache, according to an embodiment.

FIG. 8 shows a block diagram of a back-off retry system, according to anexample embodiment.

FIG. 9 shows an example time line of DNS queries that may be performedin an embodiment.

FIG. 10 shows a block diagram of an example computer system in whichembodiments of the present invention may be implemented.

The present invention will now be described with reference to theaccompanying drawings. In the drawings, like reference numbers indicateidentical or functionally similar elements. Additionally, the left-mostdigit(s) of a reference number identifies the drawing in which thereference number first appears.

DETAILED DESCRIPTION OF THE INVENTION I. Introduction

The present specification discloses one or more embodiments thatincorporate the features of the invention. The disclosed embodiment(s)merely exemplify the invention. The scope of the invention is notlimited to the disclosed embodiment(s). The invention is defined by theclaims appended hereto.

References in the specification to “one embodiment,” “an embodiment,”“an example embodiment,” etc., indicate that the embodiment describedmay include a particular feature, structure, or characteristic, butevery embodiment may not necessarily include the particular feature,structure, or characteristic. Moreover, such phrases are not necessarilyreferring to the same embodiment. Further, when a particular feature,structure, or characteristic is described in connection with anembodiment, it is submitted that it is within the knowledge of oneskilled in the art to effect such feature, structure, or characteristicin connection with other embodiments whether or not explicitlydescribed.

Furthermore, it should be understood that spatial descriptions (e.g.,“above,” “below,” “up,” “left,” “right,” “down,” “top,” “bottom,”“vertical,” “horizontal,” etc.) used herein are for purposes ofillustration only, and that practical implementations of the structuresdescribed herein can be spatially arranged in any orientation or manner.

II. Example Communication Systems

Embodiments of the present invention may be implemented in communicationsystems to enable network participants to communicate, while reducingnetwork traffic due to DNS queries. For instance, FIG. 1 shows a blockdiagram of an example communication system 100, according to anembodiment. As shown in FIG. 1, system 100 includes a firstcommunication device 102, a second communication device 104, a DNSserver 106, and a network 108. In FIG. 1, first and second communicationdevices 102 and 104 and DNS server 106 are coupled to network 108, andare enabled to communicate with each other through network 108.

Communication system 100 may be configured in various ways. Forinstance, first and second communication devices 102 and 104 may be anytype of communication device configured for communications throughnetwork 108, including VoIP communications (which may also be referredto as IP telephony, Internet telephony, voice over broadband (VoBB),broadband telephony, etc.), text messaging, web page browsing, etc.Examples of first and second communication devices 102 and 104 includeIP phones, desktop computers (e.g., a personal computer, etc.), servers,mobile computing devices (e.g., a cell phone, smart phone, a personaldigital assistant (PDA), a laptop computer, a notebook computer, etc.),etc. Network 108 may be any type of communication network, including alocal area network (LAN), a wide area network (WAN), a personal areanetwork (PAN), or a combination of communication networks, where domainname-to-address resolution is performed to enable communications. Forexample, network 108 may be an IP network, such as the Internet or otherpacket-switched network, configured for delivery of voice communications(VoIP) and/or other types of data (e.g., text messaging, web pages,etc.).

First communication device 102 may communicate with second communicationdevice 104. For instance, a first user at first communication device 102may desire to initiate a voice (e.g., VoIP) conversation with a seconduser at second communication device 104, may desire to transmit aninstant message (e.g., to the second user at second communication device104, or may desire to otherwise communicate with the second user atsecond communication device 104. In another example, a user at firstcommunication device 102 may desire to access a website hosted by secondcommunication device 104, which may be a web server. In each case, firstcommunication device 102 may have a domain name that identifies secondcommunication device 104. First communication device 102 may communicatewith DNS server 106 to resolve the domain name to an IP address forsecond communication device 104, so that first communication device 102may be enabled to transmit a communication signal to secondcommunication device 104.

For instance, as shown in FIG. 1, first communication device 102 may beconfigured to transmit a communication signal to second communicationdevice 104 through network 108. Prior to transmitting the communicationsignal, first communication device 102 transmits a DNS query 110 to DNSserver 106 through network 108. DNS query 110 includes a domain nameassociated with second communication device 104, and is a request to DNSserver 106 to provide the IP address associated with the domain name.For instance, second communication device 104 may have the associateddomain name “secondcomdevice.net,” and may have the IP address“172.16.254.1”. DNS server 106 may store domain names and associated IPaddresses for any number of communication devices, including secondcommunication device 104.

As shown in FIG. 1, DNS server 106 may receive DNS query 110. DNS server106 may determine the IP address for second communication device 104based on the domain name received in DNS query 110, and may transmit aDNS response 112 to first communication device 102 through network 108that includes the determined IP address. First communication device 102receives DNS response 112. First communication device 102 receives theIP address for second communication device 104 from DNS response 112,and transmits a communication signal 114 to second communication device104 through network 108. Communication signal 114 includes thedetermined IP address for second communication device 104, and thus canbe routed to second communication device 104.

A. Example Communication Environments

As described above, communication system 100 may have variousconfigurations, depending on the particular application. For instance,in one embodiment, first and second communication devices 102 and 104may be computing systems, and communication signal 114 may be an instantmessage. In another embodiment, first communication device 102 may be acomputing device, second communication device 104 may be a web server,and communication signal 114 may be a request for a web page. In stillanother embodiment, first and second communication devices 102 and 104may be IP phones, and communication signal 114 may be a phone call fromfirst communication device 102 to second communication device 104.

For instance, FIG. 2 shows a communication system 200, according to anembodiment. Communication system 200 is an example of communicationsystem 100 shown in FIG. 1. As shown in FIG. 2, system 200 includesfirst and second communication devices 202 and 204, first and secondDOCSIS (data over cable service interface specification) networks 206and 208, an IP network 210, a call management server (CMS) 212, anoperational support system (OSS) 214, a gateway 216, a public switchedtelephone network (PSTN) 218, an announcement server 220, a first cablemodem termination system (CMTS) 222, and a second CMTS 224.Communication system 200 enables communication devices, such ascommunication devices 202 and 204, to communicate with each otherthrough DOCSIS networks (e.g., DOCSIS networks 206 and 208) and IPnetworks (e.g., IP network 210). Note that system 200 is provided forillustrative purposes, and not all elements/features of system 200 needbe present in all embodiments. Communication system 200 is described asfollows.

First and second DOCSIS networks 206 and 208 may be any type of DOCSISnetwork, including DOCSIS HFC (hybrid fiber coaxial) access network.First CMTS 222 provides connectivity between the first DOCSIS network206 and IP network 210, and second CMTS 224 provides connectivitybetween second DOCSIS network 208 and IP network 210. As shown in FIG.2, gateway 216 may include a signaling gateway, a media gatewaycontroller, and a media gateway. The signaling gateway (SG) and themedia gateway (MG) provide connectivity between IP network 210 and PSTN218.

First and second DOCSIS networks 206 and 208 enable high-speed,reliable, and secure transport between communication devices 202 and 204(e.g., users/customers) and the cable headends at CMTS 222 and 224,respectively. First and second DOCSIS networks 206 and 208 provideDOCSIS capabilities, including Quality of Service. IP network 210 is anexample of network 108 in FIG. 1. IP network 210 provides variousfunctions, including providing an interconnection between the functionalcomponents that are responsible for signaling, media, provisioning, andthe establishment of Quality of Service on DOCSIS networks 206 and 208.In addition, IP network 210 provides long-haul IP connectivity betweenDOCSIS networks 206 and 208 and other IP networks. IP network 210 may beconsidered to include CMS 212, OSS 214, and gateway 216.

First and second communication devices 202 and 204 are examples of firstand second communication devices 102 and 104 in FIG. 1. For instance,first and second communication devices 202 and 204 may be customerpremises equipment (CPE) devices, such as telephones, computers withcommunication capability (e.g., VoIP), etc. As shown in FIG. 2, firstcommunication device 202 has an EMTA (embedded multimedia terminaladaptor) 228 a, which includes a cable modem (CM) 230 a and a multimediaterminal adapter (MTA) 232 a. Cable modem 230 a enables bidirectionalcommunications using RF (radio frequency) communication channels overfirst DOCSIS network 206, which may provide broadband Internet access inthe form of cable Internet. MTA 232 a is a VoIP adaptor that enablesVoIP communications for first communication device 202 through firstDOCSIS network 206 and IP network 210. Second communication device 204also has an embedded MTA 228 b that includes a cable modem 230 b and MTA232 b, and thus provides similar communication functionality to firstcommunication device 202.

Each MTA 232 is a client device that contains a subscriber-sideinterface to the subscriber's communication device (e.g., device 204 or206) and a network-side signaling interface to call control elements inthe network. An MTA 232 provides codecs (coder-decoders) and signalingand encapsulation functions for media transport and call signaling. MTAs232 may be connected to other network elements by the correspondingDOCSIS network (e.g., network 206 or 208). Note that in an embodiment,an EMTA 228 may include an IP address for the corresponding cable modem230 and an IP address for the corresponding MTA 232.

In the example of FIG. 2, each cable modem 230 is a network element thatis defined by DOCSIS. Each cable modem 230 is a modulator/demodulatorthat provides data transmission over the corresponding DOCSIS network(e.g., network 206 or 208) using the DOCSIS protocol. Each cable modem230 handles the media stream and provides services such asclassification of traffic into service flows, rate shaping, andprioritized queuing.

CMTS 222 and CMTS 224 each provide data connectivity and complementaryfunctionality to cable modems 230 a and 230 b, respectively, over thecorresponding DOCSIS network (e.g., network 206 or 208). Each of CMTS222 and 224 also provides connectivity to a wide area networks (e.g., IPnetwork 210), and may be located at a cable television system head-endor distribution hub. Each of CMTS 222 and 224 is responsible forallocating and scheduling upstream and downstream bandwidth inaccordance with MTA requests and QoS authorizations established by agate controller (included in CMS 212).

CMS 212 provides call control and signaling related services for theMTA, CMTS, and PSTN gateways in system 200. CMS 212 is a trusted networkelement that resides on the managed IP portion of system 200. Withregard to gateway 216, the MGC is a logical signaling managementcomponent used to control PSTN Media Gateways. The MGC maintains thecall state and controls the overall behavior of gateway 216. The MGCreceives and mediates call-signaling information between the IP network210 and PSTN 218. The MGC maintains and controls the overall call statefor calls requiring a PSTN interconnection. The MGC controls the mediagateway by instructing it to create, modify, and delete connections thatsupport the media stream over IP network 210. The signaling gateway (SG)provides a signaling interconnection function between the PSTN signalingnetwork (PSTN 218) and IP network 210. The media gateway (MG) terminatesthe bearer paths and transcodes media between PSTN 218 and IP network210.

OSS 214 includes business, service, and network management componentssupporting core business processes. As defined by the ITU TMN framework,the main functional areas for OSS are fault management, performancemanagement, security management, accounting management, andconfiguration management. As shown in FIG. 2, OSS 214 includes one ormore of a key distribution server (KDC), a provisioning server, one ormore DHCP (dynamic host configuration protocol) servers, one or more DNS(domain name system) servers 226, one or more TFTP (trivial filetransfer protocol) and/or HTTP (hypertext transfer protocol) servers, aSYSLOG server, and/or a recording keeping server (RKS).

The KDC is a security server. The DHCP server is a back office networkelement used during an MTA device provisioning process to allocate IPaddresses and other client configuration information. DNS server 226 isan example of DNS server 106 of FIG. 1, and is a back office networkelement used to map between domain names and IP addresses. The TFTPserver is a back office network element used during the MTA deviceprovisioning process to download a configuration file to the MTA. AnHTTP server may be used for the same purpose instead of a TFTP server.The SYSLOG server is an optional back office network element used tocollect event notification messages indicating that certain events suchas device errors have occurred. The RKS is a trusted network elementcomponent that receives event messages from other trusted networkelements such as the CMS, CMTS, and MGC. The RKS may act as a short-termrepository for the event messages. The RKS may assemble or correlate theevent messages into coherent sets or call detail records (CDRs), whichare then made available to other back office systems such as billing orfraud detection.

Announcement Server (ANS) 220 is a network component that manages andplays informational tones and messages in response to events that occurin IP network 210. ANS 220 includes an announcement controller (ANC) 234and an announcement player (ANP) 236. ANC 234 initiates and manages allannouncement services provided by ANP 236. ANP 236 is a media resourceserver responsible for receiving and interpreting commands from ANC 234and for delivering the appropriate announcement(s) to the MTAs.

For further detail regarding communication system 200 of FIG. 2, referto “PacketCable™ 1.5 Architecture Framework Technical ReportPKT-TR-ARCH1.5-V02-070412,” Revision IO2 released Apr. 12, 2007,copyright Cable Television Laboratories, Inc., which is incorporatedherein by reference in its entirety. As mentioned above, communicationsystem 200 (e.g., a PacketCable 1.5 architecture) is an example ofcommunication system 100 shown in FIG. 1. Note that for illustrativepurposes, embodiments may be described herein in terms of the featuresof system 200 of FIG. 2. However, such embodiments are not intended tobe limiting. Embodiments of the present invention may be implemented infurther communication system types, including those mentioned elsewhereherein, other systems that communicate over cable (e.g., a PacketCable2.0 architecture using the SIP (Session Initiation Protocol) protocol,etc.), as well as further communication systems that would be known topersons skilled in the relevant art(s).

III. Example Issues with DNS Queries, and Example Cache Embodiments

The communication systems described above may have problems whenrequests to resolve domain names fail. For example, referring to system200 of FIG. 2, a user at first communication device 202 may be desire toconduct a voice communication with a user at second communication device204 or at telephone coupled to PSTN 218. The voice communication may beconducted by EMTA 228 a of first communication device 202, through firstDOCSIS network 206 and IP network 210, to the user at secondcommunication device 204 (through second DOCSIS network 208) or at thetelephone coupled to PSTN 218. DNS server 226 may be requested by firstcommunication device 202 to provide an IP address for CMS 212 and/or forsecond communication device 204 to enable the voice communication. DNSserver 226 may fail to provide the requested IP address, and may becompletely unresponsive. Such a failure of DNS server 226 may result intelephony signal delays and interruptions leading to undesirable effectsin user experience.

When resolving a fully qualified domain name (FQDN), a communicationdevice may first access a local short term or temporary cache todetermine whether an IP address corresponding to this FQDN was storedthere previously (e.g., after the domain name was previously resolved).If the temporary cache does not store the IP address, the communicationdevice may transmit a DNS query to the DNS server. In response, the DNSserver may transmit one or more IP addresses and an associated time tolive (TTL) (e.g., time out value) for the IP address(es) to thecommunication device. The communication device may use an IP addressreceived in the response to perform a communication, and may store theIP address(es) in the temporary cache. The IP address may be stored inthe temporary cache until the TTL value expires. Use of this temporarycache for storing resolved IP addresses has the benefit of reducingdomain name resolution delays due to DNS queries, and may reduce anumber of queries transmitted to the DNS server for IP addresses thatare used regularly.

A cable company or other entity that operates DOCSIS networks may bereferred to as a multi-system operator (MSO). In an embodiment, toaddress specific MSO requirements for handling DNS server failures, anadditional “permanent” or long term cache may be maintained in firstcommunication device 202 that does not expire according to the TTL timeout value. IP addresses obtained due to successful DNS queries may bestored in the long term cache as well as the temporary cache. Whenresolution of a domain name that has previously been resolved is needed,but the TTL for the resolution has expired, and if DNS server 226 failsto provide a valid response to a DNS query, the long term cache may beaccessed for the IP address. Because an EMTA typically stores relativelyfew FQDNs in the long term cache, a loss of DNS server 226 may betolerated for long periods of time without requiring a prohibitivelylarge long term cache size.

A “back-off and retry” process may be performed by a communicationdevice after an initial failure of a DNS server to respond to a DNSquery, to repeatedly retry the DNS query after progressively longerwaiting periods. The DNS query may be repeatedly retried in the hopesthat a response is eventually received, up to a predetermined number ofretries. However, such a process results in delays associated with aneed to send multiple requests to the DNS server, and the need to waitfor each response for some predefined period of time.

For general network applications (e.g., Internet browsing, e-mailtransactions), network delays of short periods of time due to repeatedDNS query attempts may not significantly affect applicationfunctionality or user experience. For VoIP applications, however, evenshort delays may be undesirable to users. For example, when a useraccesses an IP telephone (e.g., first communication device 202) to makea call, the communication device may attempt to resolve one or moredomain names used to enable the call. Depending on the particular callflow, multiple DNS queries may be required. If domain name resolution isdelayed, a user will not hear a dial tone for the duration of theresolution process. This delay may be perceived by a user as a servicefailure and may negatively affect the user experience.

Existing solutions based on the standards that define the DNS backoffand retry behavior (RFC1034, RFC1035, RFC2308) do not meet the stringentrequirements of the VoIP Applications. In another example solution tothe retry delay, lookups may be performed proactively as each cache TTLis about to expire. In such a procedure, the DNS lookup may be performedasynchronously to the telephony application, and hence may avoid thesituation where the look up delay occurs in series. In the event of aDNS failure, the cache TTL could be reset to keep the IP addressassociated with the failed domain resolution attempt stored in thecache. However, a drawback to such an approach is that it forces DNStraffic to occur from every communication device for each DNS IP addressentry periodically at slightly less than the TTL for each DNS entry.Considering that thousands of communication devices may perform thisprocedure to maintain IP addresses, and depending on the TTL values andnumber of IP address entries, the combined amount of network traffic maybe very large, leading to network delays.

Thus, techniques are desired that enable VoIP applications to minimizedelays associated with the domain name resolution procedure.

IV. Example DNS Resolution Embodiments

In embodiments, DNS resolution techniques are provided that are morefault tolerant to potential failures at DNS servers than conventionaltechniques. Embodiments enable fewer DNS query retries to be performedwhen a DNS server is non-responsive, to reduce delays and networktraffic. In an embodiment, a number of DNS queries is reduced on acontinuous basis the longer the DNS server stays non-responsive.

For instance, FIG. 3 shows a block diagram of a DNS resolver 302,according to an example embodiment. DNS resolver 302 may be included infirst and/or second communication devices 102 and 104 shown in FIG. 1(and in first and/or second communication devices 202 and 204 shown inFIG. 2), for example. DNS resolver 302 is configured to resolve IPaddresses for domain names in a more efficient manner than inconventional techniques. As shown in FIG. 3, DNS resolver 302 includes atime-to-live (TTL)-based cache 306, a negative cache 308, and a longterm store cache 310. TTL-based cache 306 is configured to store domainnames with resolved IP addresses for time periods defined by associatedtime out or “time-to-live” values (TTLs). As such, IP addresses storedin TTL-based cache 306 expire after a period of time. Negative cache 308is configured to store negative entries that include informationindicating domain names that were failed to be resolved. Long term storecache 310 is configured to store domain names with resolved IP addressfor an indefinite time period (e.g., may be replaced with a morerecently resolved IP address for the domain name).

TTL-based cache 306, negative cache 308, and long term store cache 310may be included in one or more storage devices of a communicationdevice, such as a magnetic disc (e.g., in a hard disk drive), an opticaldisc (e.g., in an optical disk drive), a memory device such as a RAMdevice, an EPROM device (e.g., a flash memory device), etc., and/or anyother suitable type of read/write storage medium.

DNS resolver 302 is configured to determine IP addresses to enablecommunications. For example, one or more IP addresses may be needed tobe determined for one or more domain names to perform a particularcommunication (e.g., a voice communication, an instant messagecommunication, a web page request, etc.). DNS resolver 206 may accessTTL-based cache 306 to determine if an address corresponding to adesired domain name is present. As described above, entries in TTL-basedcache 306 have an expiration time. If TTL-based cache 306 does notinclude an address for the domain name, negative cache 308 may beaccessed for a negative entry associated with the domain name. Anegative entry in negative cache 308 for the domain name indicates thata previous attempt to obtain the address for the domain name from a DNSserver failed. If a negative entry is present in negative cache 308, DNSresolver 204 may access long term store cache 310 for the addresscorresponding to the domain name, which was previously stored in longterm store cache 310 after being obtained from the DNS server. If anegative entry was not present in negative cache 308, a DNS query (thatincludes the domain name) may be transmitted by DNS resolver 302 to DNSserver 106 to obtain the IP address. If the DNS query fails, DNSresolver 302 may retry the DNS query one or more times. If thesubsequent DNS queries fail, DNS resolver 204 may access long term storecache 310 for the address corresponding to the domain name.

DNS resolver 302 may be implemented in a communication device in anymanner to provide for domain name resolution. For instance, FIG. 4 showsa block diagram of communication device 102 of FIG. 1 with DNS resolver302 implemented therein, according to an example embodiment. As shown inFIG. 4, communication device 102 includes an application 402, acommunication module 404, and DNS resolver 302. Application 402 may beany application configured to enable network communications, including avoice application (e.g., a VoIP application), an instant messagingapplication, a web browser, etc. Communication module 402 is configuredto enable communication device 102 to communicate over a network, suchas network 108 of FIG. 1. Communication module 402 may include any typeof network interface (e.g., network interface card (NIC)), wired orwireless, such as an as IEEE 802.11 wireless LAN (WLAN) wirelessinterface, a Worldwide Interoperability for Microwave Access (Wi-MAX)interface, an Ethernet interface, a Universal Serial Bus (USB)interface, etc.

As shown in FIG. 4, application 402 may generate a communication request408, which may include information to be transmitted to a secondcommunication device, such as communication device 104 shown in FIG. 1,and may include a domain name associated with the second communicationdevice. Communication module 404 may receive communication request 408,and may transmit a domain name resolution request 410 to DNS resolver302 for the domain name of communication request 408. Depending on theparticular domain name, DNS resolver 302 may resolve an IP address forthe domain name (e.g., if the address is stored in TTL-based cache 306or long term store cache 310, as described above), or may generate a DNSquery 412 to request that the address be resolved by a DNS server, suchas DNS server 106 of FIG. 1. Communication module 404 receives DNS query412, and transmits DNS query 412 over network 108 to DNS server 106. DNSserver 106 may transmit a DNS response 414, which is received bycommunication module 404. DNS resolver 302 receives DNS response 414from communication module 404. If DNS response 414 includes the resolvedIP address, DNS resolver 302 transmits a resolved IP address 416 tocommunication module 404. Communication module 404 uses the receivedresolved IP address to transmit a communication signal 418 to thecommunication device having the resolved IP address. In this manner, aVoIP phone call may be established, an instant message may betransmitted, a web page may be requested, or other network communicationmay be performed.

If DNS response 414 does not include the resolved IP address, or if DNSresponse 414 is not received at all from DNS server 106, DNS resolver302 may retry DNS query 412 until a resolved IP address is received, oruntil a predetermined retry count is reached. In such case, DNS resolver302 may access long term store cache 310 for the IP address associatedwith the domain name, and may provide the IP address to communicationmodule 404 in resolved IP address 416, to be used to transmitcommunication signal 418.

Communication device 102 may perform such an IP address resolutionprocess in various ways. For instance, FIGS. 5A-5D each show portions ofa flowchart 500 that illustrates a DNS resolution procedure, accordingto example embodiment. For example, flowchart 500 may be performed bycommunication device 102 in FIG. 1. Flowchart 500 is described asfollows. Note that not all steps shown in FIGS. 5A-5D need to beperformed in all embodiments, nor do the steps shown in FIGS. 5A-5Dnecessarily need to be performed in the order shown. Other structuraland operational embodiments will be apparent to persons skilled in therelevant art(s) based on the discussion regarding flowchart 500.Flowchart 500 is described as follows.

Note that initially, DNS resolver 302 may operate in a “normal mode,” inwhich a failure to resolve a domain name with a DNS server has not yetoccurred. As described further below, if a DNS server fails to respondto a domain name resolution request, DNS resolver 302 may enter a“failure mode.” If DNS resolver 302 is subsequently able to communicatewith the DNS server and/or to resolve the domain name using the DNSserver, DNS resolver 302 may transition back to the “normal mode.”

Referring to FIG. 5A, flowchart 500 begins with step 502. In step 502,an application requests a domain name resolution. For example, as shownin FIG. 4, communication module 404 may generate domain name resolutionrequest 410, to resolve a domain name associated with communicationrequest 408 (generated by application 402) to an IP address. Forexample, a VoIP application of communication device 202 may request thedomain name resolution to enable a VoIP call to a device (e.g., secondcommunication device 104), or through a device (e.g., CMS 212), havingthe domain name requested to be resolved to an IP address.Alternatively, domain name resolution may be requested for a web server,an instant message session, or other communication. Note that in analternative embodiment, application 402 may initiate domain nameresolution request 410 directly with DNS resolver 302 (rather thanthrough communication module 404). Operation proceeds to step 504.

In step 504, a TTL-based cache is accessed for an address correspondingto the domain name. For example, as shown in FIG. 3, DNS resolver 302may access TTL-based cache 306 for an IP address corresponding to thedomain name received in a domain name resolution request. FIG. 6 shows ablock diagram of DNS resolver 302, according to an example embodiment.As shown in FIG. 6, DNS resolver 302 may include TTL-based cache 306,negative cache 308, long term store cache 310, a cache access logicmodule 602, and a DNS query generator 604. Cache access logic module 602may be configured to perform accesses of TTL-based cache 306, negativecache 308, long term store cache 310 for DNS resolver 302. For example,as shown in FIG. 6, cache access logic module 602 may receive domainname resolution request 410. Cache access logic module 602 may accessTTL-based cache 306 for an IP address corresponding to the domain namein request 410. Operation proceeds to decision 506.

For illustrative purposes, FIG. 7 shows example contents of TTL-basedcache 306, negative cache 308, long term store cache 310, according toan embodiment. The contents of TTL-based cache 306, negative cache 308,long term store cache 310 shown in FIG. 7 are provided for purposes ofillustration, and are not intended to be limiting. As shown in FIG. 7,TTL-based cache 306 may include one or more temporary entries 702, whicheach include a domain name, an IP address corresponding to the domainname, and a timeout or time to live (TTL) time value that indicates howlong the particular entry 702 will be maintained in TTL-based cache 306before expiring (e.g., before being deleted). Entries 702 may optionallyinclude further information, in embodiments. In the example of FIG. 7,two entries 702 a and 702 b are shown present in TTL-based cache 306.First entry 702 a includes the domain name “carsales.com,” thecorresponding IP address “209.77.188.166,” and the timeout value of 24hours. Second entry 702 b includes the domain name “deviceX,” thecorresponding IP address “216.77.132.1,” and the time out value of 12hours.

Negative cache 308 may include one or more negative entries 704, whicheach include a domain name. Negative entries 704 may optionally includefurther information, in embodiments. Each negative entry 704 indicatesthat a previous attempt to resolve the indicated domain name failed(e.g., an error message or no response to a DNS query was received). Inthe example of FIG. 7, one negative entry 704 a is shown present innegative cache 308. Negative entry 704 a includes the domain name“deviceY,” indicating that a previous attempt to resolve “deviceY”failed. Note that in an embodiment, negative entries 704 in negativecache 308 may expire (e.g., and be deleted) after being present innegative cache 308 for a predetermined timeout value for negative cache308.

Long term store cache 310 may include one or more long term entries 706,which each include a domain name and a corresponding IP address that waspreviously resolved for the domain name. Entries 706 may optionallyinclude further information, in embodiments. In the example of FIG. 7,three entries 706 a-706 c are shown present in long term store cache310. First entry 706 a includes the domain name “carsales.com” andcorresponding IP address “209.77.188.166” (corresponding to entry 702 ain TTL-based cache 306). Second entry 706 b includes the domain name“deviceX,” and the corresponding IP address “216.77.132.1”(corresponding to entry 702 b in TTL-based cache 306). Third entry 706 cincludes the domain name “deviceZ,” and the corresponding IP address“113.42.232.7.” No entry 706 is present in TTL-based cache 306corresponding to third entry 702 c of TTL-based cache 306, because theentry 706 expired from TTL-based cache 306 (due to its associatedtimeout value). Note that entries 706 in long term store cache 310 donot expire, although they may be replaced with updated informationreceived when the stored domain names are subsequently resolved.

Referring back to FIG. 5A, at decision 506, whether an address ispresent in TTL-based cache is determined. For example, if during theaccess of step 504, cache access logic module 602 determines that anaddress is present in TTL-based cache 306 corresponding to the domainname in request 410, operation proceeds to step 514. If cache accesslogic module 602 determines that an address is not present in TTL-basedcache 306 corresponding to the domain name, operation proceeds to step508.

In step 508, a local negative cache is accessed for a negative entrycorresponding to the domain name. For example, referring to FIG. 6,cache access logic module 602 may access negative cache 308 for anegative entry corresponding to the domain name in request 410 becausean entry was not present in TTL-based cache 306 for the domain name.Operation proceeds to decision 510.

At decision 510, whether a negative entry is present in negative cacheis determined. For example, if during the access of step 508, cacheaccess logic module 602 determines that a negative entry is present innegative cache 308 corresponding to the domain name in request 410,operation proceeds to step 512. If cache access logic module 602determines that a negative entry is not present in negative cache 308corresponding to the domain name (e.g., the negative entry timed out, orno negative entry was ever present for the domain name), operationproceeds to step 518 (in FIG. 5B).

In step 512, a local long term store cache is accessed for the addresscorresponding to the domain name. For example, cache access logic module602 may access long term store cache 310 for an IP address correspondingto the domain name in request 410. Operation proceeds to step 514.

In step 514, the communication signal is enabled to be transmitted tothe second communication device. For example, cache access logic module602 may provide the IP address accessed in long term store cache 310 tocommunication module 404 in resolved IP address 416, to enablecommunication module 404 to transmit communication signal 418 to thecommunication device having the resolved IP address.

In step 516, a next domain name resolution request is awaited.

Referring to FIG. 5B, in step 518, a DNS query is transmitted to a DNSserver to request the address corresponding to the domain name. Forexample, referring to FIG. 6, cache access logic module 602 may instructDNS query generator 604 to generate DNS query 412, which includes arequest to resolve the unresolved domain name. Communication module 404receives DNS query 412 from DNS query generator 604, and may transmitDNS query 412 to DNS server 106 (FIG. 1) to request resolution of thedomain name to an IP address. Operation proceeds to decision 520.

In decision 520, whether the DNS server responds to the DNS query isdetermined. If a response from DNS server 106 to the DNS querytransmitted in step 518 is not detected by communication module 404and/or DNS resolver 302, operation proceeds to decision 536. If aresponse from DNS server 106 is detected by communication module 404and/or DNS resolver 302, operation proceeds to decision 522.

In decision 522, whether the address or an error message is receivedfrom the DNS server in response to the DNS query is determined. Forexample, referring to FIG. 6, cache access logic module 602 may receiveDNS response 414 from communication module 404, which was received bycommunication module 404 from DNS server 106. If cache access logicmodule 602 determines that an IP address for the domain name is providedin DNS response 414, operation proceeds to step 524. If cache accesslogic module 602 determines that an error message is provided in DNSresponse 414, operation proceeds to step 528. Examples of error messagesthat may be received include NXDOMAIN (indicates a name error, where thedomain name does not exist), NODATA (indicates that the domain name isvalid, for the given class, but there are no records of the given type)and SERVFAIL (indicates a DNS server failure).

In step 524, the address is stored in the TTL-based cache and in thelong term store cache. For example, referring to FIG. 6, cache accesslogic module 602 may store the domain name, the received IP address, anda time out value received in DNS response 414 in an entry (e.g., atemporary entry 702 of FIG. 7) in TTL-based cache 306. Furthermore,cache access logic module 602 may store the domain name and the receivedIP address in an entry (e.g., a long term entry 706 of FIG. 7) in longterm store cache 310. Still further, if a negative entry for the domainname is present in negative cache 308 (e.g., a negative entry 704 ofFIG. 7), the negative entry may be removed from negative cache 308.Operation proceeds to step 526.

In step 526, the communication signal is enabled to be transmitted tothe second communication device according to the address. For example,cache access logic module 602 may provide the received IP address tocommunication module 404 in resolved IP address 416, to enablecommunication module 404 to transmit communication signal 418 to thecommunication device having the resolved IP address. Operation proceedsto step 534.

In step 528, a negative entry is stored in the negative cache. Forexample, because an error message was received from DNS server 106 inresponse to a DNS query, cache access logic module 602 may store anegative entry (e.g., a negative entry 704) in negative cache 308 toindicate the domain name for the failed DNS query. Operation proceeds tostep 530.

In step 530, the long term store cache is accessed for the addresscorresponding to the domain name. For example, cache access logic module602 may access long term store cache 310 for an IP address correspondingto the domain name of the failed DNS query. Operation proceeds to step532.

In step 532, the communication signal is enabled to be transmitted tothe second communication device using the address accessed in the longterm store cache. For example, cache access logic module 602 may providethe IP address retrieved from long term store cache 310 to communicationmodule 404 in resolved IP address 416, to enable communication module404 to transmit communication signal 418 to the communication devicehaving the retrieved IP address. Operation proceeds to step 534.

In step 534, a next domain name resolution request is awaited.Furthermore, if the current mode for DNS resolver 302 is failure mode,DNS resolver 302 transitions from failure mode to normal mode.

In decision 536, whether DNS resolver 302 is in normal mode or failuremode is determined. If DNS resolver 302 is in normal mode, operationproceeds to step 538 (FIG. 5C). If DNS resolver 302 is in failure mode,operation proceeds to decision 558 (FIG. 5D).

As shown in FIG. 6, cache access logic module 602 may include a back-offretry module 606. Back-off retry module 606 may be configured to executea back-off and retry procedure to retry a failed DNS query. Forinstance, steps 538, 540, 542, 544, and 546 shown in FIG. 5C correspondto an example back-off and retry procedure that may be performed. In anembodiment, steps 538, 540, 542, 544, and 546 may be performed byback-off retry module 606 to execute a back-off and retry procedure, orback-off retry module 606 may execute other form of back-off and retryprocedure, as would be known to persons skilled in the relevant art(s).

The back-off retry procedure of steps 538, 540, 542, 544, and 546 isdescribed for illustrative purposes with respect to FIG. 8. FIG. 8 showsa block diagram of a back-off retry system 800 that may be included incache access logic module 602, according to an example embodiment. Asshown in FIG. 8, back-off retry system 800 includes a storage 802 andback-off retry module 606. Storage 802 stores a wait time timeout value804 and a retry count value 806. Back-off retry module 606 includes aretry count modifier module 808. Back-off retry system 800 is describedfor illustrative purposes with respect to FIG. 5C.

Referring to FIG. 5C, in step 538, a length of time is waited based on apredetermined time out value. For example, as shown in FIG. 8, back-offretry module 606 may receive wait time timeout value 804 from storage802. Back-off retry module 606 is configured to wait the length of timeindicated by wait time timeout value 804. Operation proceeds to step540.

In step 540, the DNS query is transmitted to the DNS server. Forexample, cache access logic module 602 may instruct DNS query generator604 to retransmit DNS query 412, which includes the request to resolvethe unresolved domain name. Communication module 404 receives DNS query412 from DNS query generator 604, and may retransmit DNS query 412 toDNS server 106 (FIG. 1) to request resolution of the domain name to anIP address. Operation proceeds to decision 542.

In decision 542, whether the address is received from the DNS server isdetermined. If a response from DNS server 106 to the DNS querytransmitted in step 540 is not detected by communication module 404and/or DNS resolver 302, operation proceeds to decision 544. If aresponse from DNS server 106 is detected, operation proceeds to step 524(FIG. 5B).

In decision 544, whether a maximum number of retry attempts has beenperformed is determined. For example, in an embodiment, as shown in FIG.8, back-off retry module 606 may access retry count value 806 in storage802. Retry count value 806 is a predetermined value indicating a maximumnumber of DNS query retries to be performed (step 540) before indicatinga DNS server response failure. Back-off retry module 606 is configuredto count a number of DNS query retries, and when the number or retriesis equal to retry count value 806, the maximum number of retry attemptsis reached. If back-off retry module 606 determines that the maximumnumber of retry attempts has been performed, operation proceeds to step548. If the maximum number of retry attempts has not been performed,operation proceeds to step 546.

In step 546, an increased length of time is waited. For example, in anembodiment, prior to each instance of re-transmitting a DNS query duringa particular back-off retry procedure, an increased amount of time maybe waited compared to the immediately prior re-transmission. In thismanner, network bandwidth may be conserved. As shown in FIG. 8, back-offretry module 606 may receive wait time timeout value 804 from storage802. Prior to each subsequent DNS query re-transmission, back-off retrymodule 606 is configured to wait an increasingly greater length of timethan the amount of indicated by wait time timeout value 804. Forexample, the increase in time may be exponential (e.g., the amount ofwait time may be doubled, or otherwise increased, prior to each DNSquery re-transmission). Operation proceeds to step 540.

In step 548, a DNS failure is determined to have occurred, and a failuremode is entered. For example, back-off retry module 606 may indicate tocache access logic module 602 that the back-off and retry algorithmfailed to resolve the domain name, and as a result, cache access logicmodule 602 may indicate the current mode to be failure mode. Operationproceeds to step 550.

In step 550, a negative entry is stored in the negative cache. Forexample, because the most recent iteration of the back-up and retryprocedure failed, cache access logic module 602 may store a negativeentry (e.g., a negative entry 704) in negative cache 308 to indicate thedomain name that was not resolved. Operation proceeds to step 552.

In step 552, the long term store cache is accessed for the addresscorresponding to the domain name. For example, cache access logic module602 may access long term store cache 310 for an IP address correspondingto the domain name that was not resolved. Operation proceeds to step554.

In step 532, the communication signal is enabled to be transmitted tothe second communication device using the address accessed in the longterm store cache. For example, cache access logic module 602 may providethe IP address retrieved from long term store cache 310 to communicationmodule 404 in resolved IP address 416, to enable communication module404 to transmit communication signal 418 to the communication devicehaving the retrieved IP address. Operation proceeds to step 556.

In step 556, a next domain name resolution request is awaited.

FIG. 5D describes the back-off retry algorithm when in failure mode.Referring to FIG. 5D, in decision 558, whether any retry attempts areremaining is determined. Similarly to the description above, back-offretry module 606 of FIG. 8 may access retry count value 806 in storage802, which indicates a maximum number of DNS query retries to beperformed before indicating a DNS server response failure. Back-offretry module 606 is configured to count a number of DNS query retries,and when the number or retries is equal to retry count value 806, themaximum number of retry attempts is reached. If back-off retry module606 determines that any retry attempts are remaining, operation proceedsto step 562. If no retry attempts are remaining, operation proceeds tostep 560.

In step 560, the retry count value is decreased. To decrease the amountof retry attempts made during subsequent attempts to resolve the domainname where the DNS server continues to be non-responsive, the retrycount value is decreased after each cycle of DNS queries. For example,in an embodiment, as shown in FIG. 8, retry count modifier module 808may be configured to use a modify signal 810 to decrease (e.g.,decrement or otherwise reduce) the value of retry count value 806 instorage 802. Alternatively, retry count modifier module 808 may decreasea value of retry count value 806 that is read from storage 802 andmaintained in back-off retry module 606.

In step 562, a length of time is waited based on a predetermined timeout value. For example, as shown in FIG. 8, back-off retry module 606may receive wait time timeout value 804 from storage 802. Back-off retrymodule 606 is configured to wait the length of time indicated by waittime timeout value 804. Operation proceeds to step 564.

In step 564, the DNS query is transmitted to the DNS server. Forexample, cache access logic module 602 may instruct DNS query generator604 to retransmit DNS query 412, which includes the request to resolvethe unresolved domain name. Communication module 404 receives DNS query412 from DNS query generator 604, and may retransmit DNS query 412 toDNS server 106 (FIG. 1) to request resolution of the domain name to anIP address. Operation proceeds to decision 566.

In decision 566, whether the address is received from the DNS server isdetermined. If a response from DNS server 106 to the DNS querytransmitted in step 564 is not detected by communication module 404and/or DNS resolver 302, operation proceeds to decision 570. If theaddress is received from DNS server 106, operation proceeds to step 568.Note that if an error message is received from DNS server 106, in anembodiment, a negative entry may be stored in negative cache 308, longterm storage 310 may be accessed for the IP address corresponding to thedomain name, the communication signal may be transmitted to the secondcommunication device using the IP address, and a next domain nameresolution request may be waited for.

In step 568, the retry count value is reset to a predetermined originalvalue. For example, retry count modifier module 808 may be configured toreset the value of retry count value 806 to its original value instorage 802 (if retry count value 806 was decreased in storage 802), ormay be configured to read the original value of retry count value 806from storage 802 to overwrite a value for retry count value 806maintained in back-off retry module 606. In this manner, a next timethat a back-off retry algorithm is used to transmit DNS queries to theDNS server to resolve a domain name, the back-off retry algorithm willuse the original maximum number of DNS queries.

In step 570, the wait time is increased. Similarly to the descriptionfurther above, in an embodiment, prior to each instance ofre-transmitting a DNS query during a particular back-off retryprocedure, an increased amount of time may be waited compared to theimmediately prior re-transmission. In this manner, network bandwidth maybe conserved. As shown in FIG. 8, back-off retry module 606 may receivewait time timeout value 804 from storage 802. Prior to each DNS queryre-transmission, back-off retry module 606 is configured to wait anincreasingly greater length of time than the amount of indicated by waittime timeout value 804. For example, the increase in time may beexponential (e.g., the amount of wait time may be doubled, or otherwiseincreased, prior to each DNS query re-transmission). Operation proceedsto step 558.

A. Example Domain Name Resolution Request

An example domain name resolution request is described as follows withrespect to flowchart 500 of FIGS. 5A-5D and the cache entries shown inFIG. 7 for purposes of illustration. For instance, the domain name“deviceZ” may be requested to be resolved in step 502 (FIG. 5A).Referring to step 504 and decision 506, because the domain name“deviceZ” is not present in any entries 702 of TTL-based cache 306,operation would proceed to step 508. Referring to step 508 and decision510, because the domain name “deviceZ” does not have a negative entry704 in negative cache 308, operation would proceed to step 518.Referring to step 518 (FIG. 5B), the domain name of request 410,“deviceZ,” may be included in DNS query 412 transmitted to DNS server106, to be resolved to an IP address. Referring to decision 520, DNSserver 106 may not respond to DNS query 412. In such case, operationwould proceed to decision 536. Referring to step 536, if the failure torespond to the DNS query is the first such failure, DNS resolver 302 maybe in normal mode. In such case, operation would proceed to step 538(FIG. 5C).

Referring to step 538, a back-off retry algorithm is begun that includesstep 540, decision 542, decision 544, and step 546. In step 538, thetime value of wait time timeout value 804 (FIG. 8) may be waited. Instep 540, DNS query 412 may be re-transmitted to DNS server 106, toattempt to resolve “deviceZ” to an IP address. In decision 542, theaddress may not be received from DNS server 106, and thus operationproceeds to decision 544. In decision 544, initially the maximum numberof retry attempts (indicated by retry count value 806) may not bereached, and thus operation proceeds to step 546. In step 546, the waittime (which was initially wait time timeout value 804) is increased,such as by doubling wait time timeout value 804. This back-off retryalgorithm may be repeated until the number of retries reaches the valueof retry count value 806, and operation may proceed from decision 544 tostep 548.

In step 548, failure mode is entered. Operation proceeds to step 550,and a negative entry may be stored for the domain name “deviceZ” innegative cache 308. In step 552, and referring to FIG. 7, long termstore cache 310 may be accessed for the IP address of “113.42.232.7”corresponding to the domain name “deviceZ” in entry 706 c. In step 554,communication signal 418 may be transmitted to a second communicationdevice that has the IP address of “113.42.232.7.” In step 556, a nextdomain resolution request is awaited.

Subsequently, in step 502 (FIG. 5A), the domain name “deviceZ” may berequested a second time to be resolved. Referring to step 504 anddecision 506, because the domain name “deviceZ” is not present in anyentries 702 of TTL-based cache 306, operation would proceed to step 508.Referring to step 508 and decision 510, and assuming that the negativeentry entered into negative cache 308 for “deviceZ” subsequentlyexpired, operation would proceed to step 518. Referring to step 518(FIG. 5B), the domain name of request 410, “deviceZ,” may be included inDNS query 412 transmitted to DNS server 106, to be resolved to an IPaddress. Referring to decision 520, DNS server 106 may not respond toDNS query 412. In such case, operation would proceed to decision 536.Referring to step 536, DNS resolver 302 is in failure mode due to theprior failure to resolve “deviceZ.” In such case, operation wouldproceed to decision 558 (FIG. 5D).

Referring to decision 558, a back-off retry algorithm is begun thatfurther includes step 562, step 564, decision 566, and step 570. Indecision 558, initially the maximum number of retry attempts (indicatedby retry count value 806) may not be reached, and thus operationproceeds to step 562. In step 562, the time value of wait time timeoutvalue 804 (FIG. 8) may be waited. In step 564, DNS query 412 may bere-transmitted to DNS server 106, to attempt to resolve “deviceZ” to anIP address. In decision 566, the address may not be received from DNSserver 106, and thus operation proceeds to step 546. In step 546, thewait time (which was initially wait time timeout value 804) isincreased, such as by doubling wait time timeout value 804. Thisback-off retry algorithm may be repeated until the number of retriesreaches the value of retry count value 806, and operation may proceedfrom decision 558 to step 560.

In step 560, the retry count value is decreased. For example, the valueof retry count value 806 may be decremented so that one fewer DNS queryiteration is performed during the next back-off retry procedureiteration. Operation proceeds to step 550 (FIG. 5C), where a negativeentry may be stored for the domain name “deviceZ” in negative cache 308.In step 552, and referring to FIG. 7, long term store cache 310 may beaccessed for the IP address of “113.42.232.7” corresponding to thedomain name “deviceZ” in entry 706 c. In step 554, communication signal418 may be transmitted to a second communication device that has the IPaddress of “113.42.232.7.” In step 556, a next domain resolution requestis awaited.

In an embodiment, if the DNS server continues to be non-responsiveduring subsequent requests to resolve “deviceZ”, retry count value 806may be eventually decreased to zero by sufficient repetitions of step560 (FIG. 5D). Once retry count value 806 is decreased to zero, noback-off retry operations will be performed (because 0 retries will beindicated when decision 558 is reached) after the DNS query of step 540(FIG. 5C) is transmitted. In such an embodiment, one DNS query istransmitted per domain resolution request, and if no response to the DNSquery is received, a failure is indicated (and long term store cache 310may be accessed for the IP address). By reducing the number of, andeventually eliminating the back-off retry operations, the amount ofnetwork traffic due to DNS server failures is substantially reduced.

For instance, FIG. 9 shows a time line 900 of DNS queries that may beperformed in an example embodiment. In the example of FIG. 9, sixrequests to resolve an IP address for the same domain name are received,indicated at time points 902 a-902 f. As such, at each of time points902 a-902 d, a corresponding initial DNS query is transmitted (e.g.,step 518 in FIG. 5B), as indicated by dotted line in FIG. 9. In eachcase, the DNS server does not respond to the initial DNS query. As aresult, back-off retry operations are performed following a portion ofthe failed DNS queries. In the current example, for illustrativepurposes, a value of 3 is used for retry count value 806, and a value of100 milliseconds (msecs) is used for wait time timeout value 804.Furthermore, at each iteration of steps 546 (FIG. 5C) and 570 (FIG. 5D),wait time is doubled.

For example, with regard to the DNS query at time point 902 a, becauseno response is received, back-off retry operation 904 a is performed(starting at step 538 in FIG. 5C), in which the DNS query isre-transmitted a total of three times—at each of time points 906 a-906c. 100 milliseconds of time passes between the DNS queries at timepoints 906 a and 906 b, and 200 milliseconds of time passes between theDNS queries at time points 906 b and 906 c. Because retry count value806 is 3, back-off retry operation 904 a ends after three DNS queryretransmissions, and because no response is received from the DNSserver, failure mode is entered (step 548).

With regard to the DNS query at time point 902 b, because no response isreceived, back-off retry operation 904 b is performed (starting atdecision 558 in FIG. 5D), in which the DNS query is re-transmitted atotal of three times—at each of time points 908 a-908 c. 100milliseconds of time passes between the DNS queries at time points 908 aand 908 b, and 200 milliseconds of time passes between the DNS queriesat time points 908 b and 908 c. Because the retry count value is 3,back-off retry operation 904 b ends after three DNS queryretransmissions. Furthermore, the retry count value is decreased (step560 of FIG. 5D) (from 3 to 2 in the current example).

With regard to the DNS query at time point 902 c, because no response isreceived, back-off retry operation 904 c is performed (starting atdecision 558 in FIG. 5D), in which the DNS query is re-transmitted atotal of two times—at each of time points 910 a and 910 b. 100milliseconds of time passes between the DNS queries at time points 910 aand 910 b. Because the retry count value is 2, back-off retry operation904 c ends after two DNS query retransmissions. Furthermore, the retrycount value is decreased (step 560 of FIG. 5D) from 2 to 1 in thecurrent example.

With regard to the DNS query at time point 902 d, because no response isreceived, back-off retry operation 904 d is performed (starting atdecision 558 in FIG. 5D), in which the DNS query is re-transmitted onetime—at time point 912 a. Because the retry count value is 1, back-offretry operation 904 d ends after one DNS query retransmission.Furthermore, the retry count value is decreased (step 560 of FIG. 5D)from 1 to 0 in the current example.

With regard to the DNS query at time point 902 e, no response isreceived. However, because the retry count value is zero, no back-offretry operation is performed. Similarly, with regard to the DNS query attime point 902 f, no response is received, and because the retry countvalue is zero, no back-off retry operation is performed. In a similarfashion, no back-off retry operations will be performed for subsequentfailed DNS queries until after a DNS query receives a response from theDNS server that includes a domain name resolution, and the modetransitions from failure mode back to normal mode (e.g., step 534 ofFIG. 5B).

B. Further Example Embodiments and Advantages

Negative caching using negative cache 308 works in conjunction with longterm caching by storing DNS lookup failures for a defined timeout periodso that subsequent lookups on a domain name will be taken directly fromlong term store cache 310 rather than continuously retrying a DNS query.With an entry in negative cache 308, a cumulative timeout periodinherent in a rapid succession of failed DNS lookups may be avoided,thereby satisfying timing requirements.

RFC 2308 recommends that for error messages (e.g., NXDOMAIN, NODATA andSERVFAIL), a Start Of Authority (SOA) record TTL can be used as TTL fornegative caching. This RFC has a requirement on DNS servers to includethe SOA record in their response, but experience has shown that many DNSservers do not follow all the RFC requirements. Thus, in an embodiment,a configured value may be used instead.

DNS RFCs (request for comments) 1034 and 1035 specify a simple algorithmfor back-off retry for DNS resolvers, similar to the back-off retryalgorithm described above. DNS RFCs 1034 and 1035 state that if DNSservers are non-responsive, a DNS resolver should timeout and retry alimited number of times. Specific timeout values or number of retriesare not specified. Current EMTA DNS resolvers uses timeout values of 2seconds, a number of retries value of 3, and an exponential backoffretry algorithm. The delay can then be estimated as the timeout valuemultiplied by the retry count. For example, a maximum delay can be asmuch asSUM 1:N(Tn), where Tn=2×Tn−1  Equation 1where

Tn=the timeout value, and

N=the number of retries.

So for a timeout value (Tn) (wait time timeout value 804) of 2 seconds,and a retry count value (N) (retry count value 806) of 3, the delay maybe 14 seconds.

Configurability: In embodiments, the following parameters may be madeconfigurable so that the operators can set them depending on the trafficand demands of their networks. For example, in a VoIP application, ifthe maximum tolerance for receiving a dial tone is 1.5 seconds, then thewait time timeout value can be set to 0.5 seconds and the retry countvalue may be initialized to 2, totaling 1.5 seconds, before an entry isretrieved from long term store cache 310. The following managementinformation bases (MIBs) are examples that may be used to configurevarious system parameters.

Timeout value for DNS queries: The following MIB may be used toconfigure the wait time timeout value used for DSN queries:

emtaBaseDnsBaseTimeout OBJECT-TYPE SYNTAX Unsigned32 UNITS“milliseconds” MAX-ACCESS read-write STATUS current DESCRIPTION ″Thisobject controls the base timeout value for DNS queries. The DNS clientDNS query times out due to no response from the DNS server, the EMTA DNSresolver waits this period of time before sending the next DNS Query ifno response is received from the DNS server. This is exponentiallyincreased on subsequent DNS queries for the same transaction.″ DEFVAL{500}

Max Retry value for DNS retries: The following MIB may be used toconfigure the maximum/initial retry count value for DNS queries:

emtaBaseDnsMaxRetry OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-writeSTATUS current DESCRIPTION “This object controls the maximum retry valuefor a DNS queries. When a DNS query times out due to no response fromthe DNS server, this is the maximum number of times that a DNS query isre-sent.” DEFVAL {2}

Maximum TTL for Negative DNS RRs: The following MIB may be used toconfigure the timeout/expiration time value used for negative caching(negative cache 308):

emtaBaseDnsNegativeCacheTTL OBJECT-TYPE SYNTAX Unsigned32 UNITS“seconds” MAX-ACCESS read-write STATUS current DESCRIPTION ″This objectcontrols the maximum TTL value for DNS negative cache RRs. When a DNSquery results in a response of NXDOMAIN, NODATA or SRVFAIL, and no SOARR is included in the response, or due to a non-responsive DNS serverthe EMTA DNS resolver caches the negative RR with this TTL value.″DEFVAL {300}

Example advantages: Currently EMTAs have little to no DNS faulttolerance. Referring to FIG. 2, if DNS server 226 is non-responsive andthe cache for an entry is expired, EMTA performs a DNS backoff retryprocedure. According to current hard-coded timeout values of 2 secondsand a retry count of 2, such a backoff retry procedure takesapproximately 14 seconds. As there is no response, the FQDN is notresolved and a user never receives a response to voice activity. Forexample, the user may not receive a dial tone when the phone goesoff-hook.

In one improvement, the timeout value is reduced from 2 seconds to 500milliseconds. This results in reducing the backoff retry procedure from14 seconds to 2.5 seconds. With this improvement, the backoff retryprocedure runs to completion considerably faster, but if there is afailure, the user experience is not changed.

The addition of the permanent cache resolves the problem of the usernever receiving a response to a DNS query, but leaves the issue of thelong delay of 2.5 seconds before the response. This is because the EMTAneeds to resolve the DNS address, and needs to get the latest updatedDNS resolution as well as handling DNS servers that respond too slowlyor suffer from excessive network traffic. So with current settings, theuser may receive a response in around 2.5 seconds, which is fairlynoticeable and could be improved.

In a further embodiment, negative caching, as described above, is usedto resolve the delay issue. Negative caching saves the result of failedlookups for a fixed period of time (e.g., 5 minutes). On the firstattempt, the user will experience the delay of 2.5 seconds which isacceptable, but still a slightly noticeable delay, as the EMTA (e.g.,DNS resolver 204) tries to resolve the FQDN going through its backoffretry procedure. Once the EMTA determines that the FQDN resolution hasfailed due to a DNS server failure, this is cached as a negative cache.Therefore for the next five minutes, the user experiences no delays andhas normal voice activity. Every 5 minutes, the user will observe thesame short delay followed by 5 minutes of normal response time. Thiswill continue until the DNS server is back online. Further enhancementsare described as follows:

Configurability: The timeout, retry count and the negative cache TTL maybe configured in any manner, including by SNMP (simple networkmanagement protocol). For example, these values may be obtained byaccessing an SNMP server across a network. This approach enables theoperator to choose the optimum values for their networks. Operators cangather statistics on the DNS server responses, their maximum and minimumdelays and set these values accordingly to make the user experience morepleasant. For example, these values may be set according to the MIBsdescribed above, or in another manner.

Adaptive Fault Tolerance: With the adaptive approach, the delaysexperienced by the user for every 5 minutes are reduced as the DNSserver stays non-responsive. EMTA will reduce the number of retriesevery 5 minutes and the user will experience less delays. After thenegative cache has expired as many times as the retry count, the userwill experience no delays as the EMTA have adapted to the non-responsiveDNS server. For example with timeout of 500 ms and retry count of 2, theuser will experience a 2 second delay on the first attempt, a 1 seconddelay after 5 minutes, and a relatively unnoticeable 500 ms delay forthe rest of the time until DNS server 226 comes back to a responsivestate.

There can be serious problems when DNS servers fail, especially forVoice applications. This algorithm prevents the network from beingflooded with DNS queries as voice signaling tries to connect and getresponse from signaling servers.

Further example advantages that may be provided by embodiments includecontinued voice service even in the case of a DNS server outage, reducednetwork traffic upon failures, and service providers being able toconfigure the fault tolerance parameters for optimal network traffic.

V. Example Computer Implementations

DNS resolver 302, DNS query generator 604, back-off retry module 606,and retry count modifier module 808 may be implemented in hardware,software, firmware, or any combination thereof. For example, DNSresolver 302, DNS query generator 604, back-off retry module 606, and/orretry count modifier module 808 may be implemented as computer programcode configured to be executed in one or more processors. Alternatively,DNS resolver 302, DNS query generator 604, back-off retry module 606,and/or retry count modifier module 808 may be implemented as hardwarelogic/electrical circuitry.

The embodiments described herein, including systems, methods/processes,and/or apparatuses, may be implemented using well knownservers/computers, such as a computer 1000 shown in FIG. 10. Forexample, communication devices 102 and 104, communication devices 202and 204, and/or DNS server 106 can be implemented using one or morecomputers 1000. Computer 1000 is described as follows, for purposes ofillustration. Alternatively, as described above, communication devices102 and 104 and communication devices 202 and 204 may be implemented inother forms, such as IP telephones, for example.

Computer 1000 can be any commercially available and well known computercapable of performing the functions described herein, such as computersavailable from International Business Machines, Apple, Sun, HP, Dell,Cray, etc. Computer 1000 may be any type of computer, including adesktop computer, a server, etc.

Computer 1000 includes one or more processors (also called centralprocessing units, or CPUs), such as a processor 1004. Processor 1004 isconnected to a communication infrastructure 1002, such as acommunication bus. In some embodiments, processor 1004 cansimultaneously operate multiple computing threads.

Computer 1000 also includes a primary or main memory 1006, such asrandom access memory (RAM). Main memory 1006 has stored therein controllogic 1028A (computer software), and data.

Computer 1000 also includes one or more secondary storage devices 1010.Secondary storage devices 1010 include, for example, a hard disk drive1012 and/or a removable storage device or drive 1014, as well as othertypes of storage devices, such as memory cards and memory sticks. Forinstance, computer 1000 may include an industry standard interface, sucha universal serial bus (USB) interface for interfacing with devices suchas a memory stick. Removable storage drive 1014 represents a floppy diskdrive, a magnetic tape drive, a compact disk drive, an optical storagedevice, tape backup, etc.

Removable storage drive 1014 interacts with a removable storage unit1016. Removable storage unit 1016 includes a computer useable orreadable storage medium 1024 having stored therein computer software1028B (control logic) and/or data. Removable storage unit 1016represents a floppy disk, magnetic tape, compact disk, DVD, opticalstorage disk, or any other computer data storage device. Removablestorage drive 1014 reads from and/or writes to removable storage unit1016 in a well known manner.

Computer 1000 also includes input/output/display devices 1022, such asmonitors, keyboards, pointing devices, etc.

Computer 1000 further includes a communication or network interface1018. Communication interface 1018 enables the computer 1000 tocommunicate with remote devices. For example, communication interface1018 allows computer 1000 to communicate over communication networks ormediums 1042 (representing a form of a computer useable or readablemedium), such as LANs, WANs, the Internet, etc. Network interface 1018may interface with remote sites or networks via wired or wirelessconnections.

Control logic 1028C may be transmitted to and from computer 1000 via thecommunication medium 1042.

Any apparatus or manufacture comprising a computer useable or readablemedium having control logic (software) stored therein is referred toherein as a computer program product or program storage device. Thisincludes, but is not limited to, computer 1000, main memory 1006,secondary storage devices 1010, and removable storage unit 1016. Suchcomputer program products, having control logic stored therein that,when executed by one or more data processing devices, cause such dataprocessing devices to operate as described herein, represent embodimentsof the invention.

Devices in which embodiments may be implemented may include storage,such as storage drives, memory devices, and further types ofcomputer-readable media. Examples of such computer-readable storagemedia include a hard disk, a removable magnetic disk, a removableoptical disk, flash memory cards, digital video disks, random accessmemories (RAMs), read only memories (ROM), and the like. As used herein,the terms “computer program medium” and “computer-readable medium” areused to generally refer to the hard disk associated with a hard diskdrive, a removable magnetic disk, a removable optical disk (e.g.,CDROMs, DVDs, etc.), zip disks, tapes, magnetic storage devices, MEMS(micro-electromechanical systems) storage, nanotechnology-based storagedevices, as well as other media such as flash memory cards, digitalvideo discs, RAM devices, ROM devices, and the like. Suchcomputer-readable storage media may store program modules that includecomputer program logic for DNS resolver 302, DNS query generator 604,back-off retry module 606, and retry count modifier module 808, and/orflowchart 500 (including any one or more steps of flowchart 500), and/orfurther embodiments of the present invention described herein.Embodiments of the invention are directed to computer program productscomprising such logic (e.g., in the form of program code or software)stored on any computer useable medium. Such program code, when executedin one or more processors, causes a device to operate as describedherein.

The invention can work with software, hardware, and/or operating systemimplementations other than those described herein. Any software,hardware, and operating system implementations suitable for performingthe functions described herein can be used.

CONCLUSION

While various embodiments of the present invention have been describedabove, it should be understood that they have been presented by way ofexample only, and not limitation. It will be apparent to persons skilledin the relevant art that various changes in form and detail can be madetherein without departing from the spirit and scope of the invention.Thus, the breadth and scope of the present invention should not belimited by any of the above-described exemplary embodiments, but shouldbe defined only in accordance with the following claims and theirequivalents

What is claimed is:
 1. A method in a first communication client device,comprising: receiving a request to resolve an address for a domain namecorresponding to a second communication device; accessing a time-to-live(TTL)-based cache of the first communication client device for theaddress; accessing a negative cache of the first communication clientdevice for a negative entry corresponding to the domain name if theaddress is not present in the TTL-based cache; accessing a long termstore cache of the first communication client device for the address ifthe negative entry is present in the negative cache, wherein the longterm store cache is configured to store addresses corresponding torespective domain names for an indefinite time period; and enabling acommunication signal to be transmitted to the second communicationdevice according to the address if the address is present in at leastone of the TTL-based cache or the long term store cache.
 2. The methodof claim 1, wherein if the address is not present in the TTL-based cacheand the negative entry is not present in the negative cache, performing:transmitting a DNS (domain name system) query to a DNS server to requestthe address; storing the address in the TTL-based cache and in the longterm store cache if the address is received from the DNS server inresponse to the DNS query; enabling the communication signal to betransmitted to the second communication device according to the addressif the address is received from the DNS server in response to the DNSquery; and storing a negative entry in the negative cache, accessing thelong term store cache for the address, and enabling the communicationsignal to be transmitted to the second communication device using theaddress accessed in the long term store cache if the DNS server providesan error message in response to the DNS query.
 3. The method of claim 2,wherein if the DNS server does not respond to the transmitted DNS query,performing: executing a back-off retry operation having a retry countvalue that defines a number of retry attempts for transmitting the DNSquery to the DNS server; determining that a DNS failure has occurred ifthe number of retry attempts corresponding to the retry count value isperformed without receiving the requested address from the DNS server;and entering a failure mode if a DNS failure is determined to haveoccurred.
 4. The method of claim 3, wherein said executing a back-offretry operation comprises: waiting a length of time based on apredetermined time out value; transmitting the DNS query to the DNSserver after the length of time expires; and waiting an increased lengthof time and retransmitting the DNS query to the DNS server after theincreased length of time each time that the DNS server does not respondto the transmitted DNS query until the retry count value for theback-off retry operation is reached.
 5. The method of claim 3, whereinif the address is received from the DNS server in response to a DNSquery during the back-off retry operation, performing: storing theaddress in the TTL-based cache and in the long term store cache; andenabling the communication signal to be transmitted to the secondcommunication device.
 6. The method of claim 3, wherein if a DNS failureis determined to have occurred, performing; decrementing the retry countvalue; storing the negative entry in the negative cache; accessing thelong term store cache for the address; and enabling the communicationsignal to be transmitted to the second communication device according tothe address accessed in the long term store cache.
 7. The method ofclaim 6, further comprising: receiving a second request to resolve theaddress for the domain name; accessing the negative cache for thenegative entry corresponding to the domain name; transmitting a secondDNS query to the DNS server to request the address if the negative entryis not present in the negative cache; re-executing the back-off retryoperation having a number of retry attempts indicated by the decrementedretry count value if the DNS server does not respond to the transmittedsecond DNS query; and decreasing the decremented retry count value,storing the negative entry in the negative cache, accessing the longterm store cache for the address, and enabling a second communicationsignal to be transmitted to the second communication device according tothe address accessed in the long term store cache if the DNS server doesnot respond to the transmitted second DNS query during the re-executedback-off retry operation.
 8. The method of claim 7, wherein if theaddress is received from the DNS server in response to the second DNSquery during the re-executed back-off retry operation, performing:resetting the decremented retry count value to a predetermined originalretry count value; storing the address in the TTL-based cache and in thelong term store cache; and enabling a second communication signal to betransmitted to the second communication device.
 9. A first communicationclient device, comprising: a DNS (domain name system) resolverconfigured to process a request to resolve an address for a domain namecorresponding to a second communication device, the DNS resolverincluding a time-to-live (TTL)-based cache of the first communicationclient device; a negative cache of the first communication clientdevice; a long term store cache of the first communication clientdevice; and a cache access logic module configured to access theTTL-based cache for the address; wherein the cache access logic moduleis configured to access the negative cache for a negative entrycorresponding to the domain name if the address is not present in theTTL-based cache; wherein the cache access logic module is configured toaccess the long term store cache for the address if the negative entryis present in the negative cache, wherein the long term store cache isconfigured to store addresses corresponding to respective domain namesfor an indefinite time period; and wherein the cache access logic moduleis configured to enable the communication signal to be transmitted tothe second communication device according to the address if the addressis present in at least one of the TTL-based cache or the long term storecache.
 10. The first communication client device of claim 9, wherein ifthe address is not present in the TTL-based cache and the negative entryis not present in the negative cache, the cache access logic module isconfigured to transmit a DNS (domain name system) query to a DNS serverto request the address, to store the address in the TTL-based cache andin the long term store cache if the address is received from the DNSserver in response to the DNS query, and to enable the communicationsignal to be transmitted to the second communication device according tothe address if the address is received from the DNS server in responseto the DNS query; and wherein the cache access logic module isconfigured to store a negative entry in the negative cache, to accessthe long term store cache for the address, and to enable thecommunication signal to be transmitted to the second communicationdevice using the address accessed in the long term store cache if theDNS server provides an error message in response to the DNS query. 11.The first communication client device of claim 10, wherein the cacheaccess logic module includes a back-off retry module; and wherein if theDNS server does not respond to the transmitted DNS query, the back-offretry module is configured to execute a back-off retry operation havinga predetermined retry count value that defines a number of retryattempts for transmitting the DNS query to the DNS server, and the cacheaccess logic module is configured to enter a failure mode if the numberof retry attempts corresponding to the retry count value is performedwithout receiving the requested address from the DNS server.
 12. Thefirst communication client device of claim 11, wherein in order toexecute the back-off retry operation, the back-off retry module isconfigured to wait a length of time based on a predetermined time outvalue, to enable the DNS query to be transmitted to the DNS server afterthe length of time expires, and to wait an increased length of time andenable the DNS query to be retransmitted to the DNS server after theincreased length of time each time that the DNS server does not respondto the transmitted DNS query until the retry count value for theback-off retry operation is reached.
 13. The first communication clientdevice of claim 11, wherein if the address is received from the DNSserver in response to a DNS query during the back-off retry operation,the cache access logic module is configured to store the address in theTTL-based cache and in the long term store cache and to enable thecommunication signal to be transmitted to the second communicationdevice.
 14. The first communication client device of claim 11, whereinif the cache access logic module is in failure mode, the back-off retryis configured to decrement the retry count value, and the cache accesslogic module is configured to store the negative entry in the negativecache, to access the long term store cache for the address, and toenable the communication signal to be transmitted to the secondcommunication device according to the address accessed in the long termstore cache.
 15. The first communication client device of claim 14,wherein if a second request to resolve the address for the domain nameis received: the cache access logic module is configured to access thenegative cache for the negative entry corresponding to the domain name,and to enable a second DNS query to be transmitted to the DNS server torequest the address if the negative entry is not present in the negativecache; the back-off retry module is configured to re-execute theback-off retry operation having a number of retry attempts indicated bythe decremented retry count value if the DNS server does not respond tothe transmitted second DNS query, and to decrease the decremented retrycount value; and the cache access logic module is configured to storethe negative entry in the negative cache, to access the long term storecache for the address, and to enable a second communication signal to betransmitted to the second communication device according to the addressaccessed in the long term store cache if the DNS server does not respondto the transmitted second DNS query during the re-executed back-offretry operation.
 16. The first communication client device of claim 15,wherein if the address is received from the DNS server in response tothe second DNS query during the re-executed back-off retry operation,the back-off retry module is configured to reset the decremented retrycount value to a predetermined original retry count value, and the cacheaccess logic module is configured to store the address in the TTL-basedcache and in the long term store cache, and to enable a secondcommunication signal to be transmitted to the second communicationdevice.
 17. The first communication client device of claim 10, whereinthe first communication device is coupled to the DNS server through aDOCSIS (data over cable service interface specification) network. 18.The first communication client device of claim 9, wherein the firstcommunication device is an internet protocol (IP) telephone.
 19. Thefirst communication client device of claim 9, wherein the communicationsignal is an instant message.
 20. A computer readable storage devicehaving computer program logic embodied in said computer readable storagemedium for enabling a processor to process a request to resolve anaddress for a domain name corresponding to a communication device, thecomputer program logic including program code executable to performoperations comprising: accessing a time-to-live (TTL)-based cache of thefirst communication client device for the address; accessing a negativecache of the first communication client device for a negative entrycorresponding to the domain name if the address is not present in theTTL-based cache; accessing a long term store cache of the firstcommunication client device for the address if the negative entry ispresent in the negative cache, wherein the long term store cache isconfigured to store addresses corresponding to respective domain namesfor an indefinite time period; and enabling a communication signal to betransmitted to the communication device according to the address if theaddress is present in at least one of the TTL-based cache or the longterm store cache.